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RECEIVED 

NOV 0* 3 2004 

Victoria Savac ool (LCA) W $ -r , . n * , nenn 

' ' % ^ s Technology Contpr ?fflO 

From: IkkoFushiki x ^ 

Sent: Thursday, *' 

To: Gary Starkweather 

Cc: GDI+ Leads 

Subject: RE: sRGB extension 

Thanks Gary. We would like to have a floating point. But as a hardware and internal strage point of view, a floating point 
requires at least 32 bit of acuracy for each component and we have to use 128 bit for one color. For a natural extension of 
32bit color, we are extendning to 64 bit at this moment with 16 bit for each component. 

I will propose this idea to our next group meeting. 

Ikko 

— Original Message — 
From: Gary Starkweather 

Sent: Thursday, 
To: Ikko FushiKi 

Cc GDI+ Leads 

Subject: RE: sRGB extension 

I think it is a good idea. The ICC is already grappling with the need for 16 bit LUTs since the 8 bit are just too 
restrictive. Microsoft can take the lead here and provide this extended capability which will be required in the future 
One of my proposals to the RIWG (Reference Impementation Working Group) was that we also look forward to a 
floating point capability so that roundoff, when it is necessary can be accomplished last to preserve as much precision 
as possible, this was disliked in the past since the PCs and Macs were much slower with FP calcs. That is no longer 
the case for the most part. Your approach looks like a good solution. 

-Gary 

— Original Message — 
From: Ikko Fushiki 
Sent: Wednesday, 
To: Gary Starkweather 
Cc: GDI+ Leads 
Subject: sRGB extension 

Gary: 

I'm thinking of sRGB extension for GDI+. Currently, we have only 8 bit for each channel. When we linearlize the 
8bit, the rounding error causes unpleasant result. We are thinking of extending the color format to 16 bit for each 
channel. 

The use of 16 bit certainly solve the rounding problem associated with gamma correction. But it does not solve 
ICM problem. If we regard the 16 bit as value 0 to 1, the total gammut is still the same. This does not cover the 
wider range of gammut for other devices. 

The linearlized sRGB is related with CIE XYZ by a Matrix. In sRGB spec, both r, g, b and X, Y, Z are normalized 
to 1. If we have an ideal phosphers (rO, gO, bO), it will be related with X = rO, Y = gO, and Z = bO. The gamut of 
this ideal phospers will be a triangle in (x, y)-space with both x and y ranging from 0 to 1. 
In order to express this ideal gamut in sRGB, its values must range 

- 2.0360 <=Rs<= 3.24 * 
-0.9692 <=Gs<= 1.9176 

- 0.2040 <=Bs<= 1.126 

This mean that if we allow 4 bit for an integer part of each component, it can range from - 7 to 7 Then we can use 
the remaining 12 bits for the decimal part of the component. This 4.12 scheme will help ICM. 

Let me know how you think of this extension. 

Ikko 
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